Embodiments relate to databases, and in particular, to extending a database language to accommodate calculation expressions in enhanced data models.
Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Many database structures rely upon Structured Query Language (SQL) as the standard approach to define, read, and manipulate data within a database. At a low level, such a database may employ fundamental data definition and processing that is based upon a relational model. In particular, a data definition defines a data type with sufficient metadata being associated therewith. A data definition may also involve definition of a database structure such as columns and tables. Many database structures rely upon Structured Query Language (SQL) as the standard database language to define, read, and manipulate data within a database. In its standard form, SQL itself reflects the basic relational model of the database. Various other types of applications (e.g. toolsets) are constructed by developers to allow consumers to interact with the database in an efficient and intuitive manner. Such applications are typically provided in an application layer overlying the database.
The overlying applications, such as consumer technology and toolsets provided by developers, may introduce higher-level models, e.g., entity-relationship models (ERMs) in order to contribute semantics and ease consumption by the user. In particular, a plain data model on the SQL level only contains the requisite information to process data on the SQL-level. Adding more information in a declarative fashion provides potential for higher-level engines to offload work from developers by contributing more semantics. Adding more information in a declarative fashion can also make data models more comprehensible, thereby easing their consumption by users.
One example of a higher-level model is an OData Entity Data Model (EDM). In particular, OData is a web protocol standard providing platform-agnostic interoperability for querying and updating data. OData leverages web technologies such as HTTP, Atom Publishing Protocol (AtomPub), and JSON (JavaScript Object Notation) in order to provide access to information from a variety of applications. The simplicity and extensibility of OData can provide consumers with a predictable interface for querying a variety of data sources.
Other examples of higher level models may include the Semantic Layer in the Business Intelligence (BI) platform of SAP AG, in Walldorf, Germany, Java Persistence API (JPA) and enterprise objects in Java, or the business objects frameworks in Advanced Business Application Programming language (ABAP). Also, the River programming model and the River Design Language (RDL) of the River Application Development framework for SAP AG, in Walldorf, Germany, are based upon entities linked by relationships.
Even though those higher-level models may share many commonalities, the individual information cannot be shared across stacks. That is, the higher-level models mentioned above contribute essentially the same kind of additional information, yet that information is provided in different ways that interfere with its being shared across higher level models (e.g., between an OData EDM and an ERM created using RDL).
This situation results in a fragmented environment, with information unable to be shared between applications. To cope with this fragmentation, redundant information is provided with application developers and customers contributing the same essential information in multiple forms, thereby undesirably increasing overhead.
Furthermore, while the developers of consumer technologies may have some knowledge of SQL, they are generally not experts in complex SQL programming.
It is also noted that when retrieving data from tables in a database, new data attributes may be calculated transiently based on the values of other attributes, utilizing a calculation expression. In order to interact with a relational database utilizing conventional SQL, such calculation expressions may need to be redundantly placed in many locations within the code. Thus, there is a need for an improved language for interacting with relational databases.